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DETAILED ACTION 

1. Claims 1-15 are subject to examination. Claims 16-57 are cancelled. 

Response to Arguments 

2. Applicant's arguments filed 7/5/2005, pages 7-11, have been fully considered but they are 
not persuasive. Therefore, rejection of claims 1-15 is maintained. 

Applicant argues (1), "the combined references do not disclose, teach, or suggest 
amended claim 1 . In particular, the combined references fail to disclose, teach or suggest the 
applicant's claimed selectively storing the multimedia file on at least one of the application 
server and the streaming server based on a number of client requests received for the multimedia 
file". The examiner respectfully disagrees in response to applicant's arguments. The limitations, 
"selectively storing the multimedia file on at least one of the application server and the streaming 
server based on a number of client requests received for the multimedia file", has been nev^ly 
added, v^hich is addressed by the nev^ ground(s) of rejection (please refer to the below rejections 
of this office action), necessitated by the applicant's amendment. Therefore, the rejection is 
maintained. 

Applicant argues (2), "the cited art Day et al., IBM, 5,996,015 (Hereinafter Day-IBM) 
fails to teach or suggest claimed storing on an application server multimedia data and a 
streaming server that converts multimedia data, the method comprising steps for sending the 
multimedia data, receiving of a client request and converting of multimedia data a format 
readable by the at least one client apparatus". The examiner respectfiilly disagrees in response to 
applicant's arguments. The limitations of the claimed subject matter is rejected by combined 
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teachings of Day-IBM and Saxena et al., 5,805,821, IBM (Hereinafter Saxena-IBM). In response 
to applicants arguments against the references individually, one cannot show nonobviousness by 
attacking references individually where the rejections are based on combinations of references. 
See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co,, 800 F.2d 1091, 
231 USPQ 375 (Fed. Cir. 1986). Day-IBM discloses storing on an application server (e.g., col., 
4, lines 42 - 55, figure 2) a multimedia file including a plurality groups of multimedia data (e.g., 
col., 6, lines 45 - 64); converting (e.g., col., 6, lines 21 - 25) at the streaming server (col., 3, lines 
19-26, figures 1 and 2), each of the media information received from the buffer (e.g., col., 4, 
lines 42 - 55, figures 1 and 2) and sending the multimedia data (e.g., coL, 5, lines 7 - 29), 
receiving of a client request (e.g., col., 5, lines 40-51) and converting of multimedia data (e.g., 
col., 6, lines 21 - 25) a format readable by the at least one client apparatus (e.g., col., 5, lines 36 - 
48). Day-IBM also discloses usage of different servers including application server and a 
streaming server (e.g., col., 4, lines 42 - 55, col., 3, lines 19-26, figures 1 and 2), and well- 
known concept of usage of the servers, i.e., combined or separated (e.g., col., 3, lines 21 -26). 
Saxena-IBM discloses the well-known concept of each group having a predetermined data size 
(e.g., col., 31, lines 1 - 41, figures 16 - 21), reading a client address corresponding to at least one 
client apparatus (e.g., col., 22, lines 3 - 40, figures 7, 1 1), stripping consecutive groups (e.g., 
col., 31, lines 1-41, figures 16-21) and buffering the consecutive groups in a staging buffer 
(e.g., col., 8, lines 44 - 56). With the combined teachings of Day-IBM and Saxena-IBM, the 
stripping of the consecutive groups would help select necessary data. The consecutive data 
would help the software to process the information to support the client. The staging buffer 
would help store stripped information in a consecutive manner. Group having a predetermined 
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data size would help the software to process data for the client. The client address would help 
the device to support transfer of data to the client. Also, the specification, page 13, lines 16-19, 
clearly states, "the scope of the present invention is not limited to data communication systems 
disclosed". Since, applicants claims contain broadly claimed subject matter, it clearly reads 
upon the examiner's interpretation of the claimed subject matter. Therefore, the rejection is 
maintained. 

Applicant argues (3), "Saxena-IBM do not disclose, teach, or suggest the applicant's 
claimed selectively storing the multimedia file on at least one of the application server and the 
streaming server based on a number of client requests received for the multimedia file". The 
examiner respectfully disagrees in response to applicant's arguments. The limitations, 
"selectively storing the multimedia file on at least one of the application server and the streaming 
server based on a number of client requests received for the multimedia file", has been newly 
added, which is addressed by the new ground(s) of rejection (please refer to the below rejections 
of this office action), necessitated by the applicant's amendment. Therefore, the rejection is 
maintained. 

Applicant argues (4), "the cited art Mattaway-NetSpeak fails to teach or suggest claimed 
determining, in a request handler, a number of client requests from at least one client apparatus 
for a multimedia file. The examiner respectfiilly disagrees in response to applicant's arguments. 
The limitations of the claimed subject matter is rejected by combined teachings of Day-IBM, 
Saxena-IBM, Raz-AppStream and Mattaway-NetSpeak. In response to applicant's arguments 
against the references individually, one cannot show nonobviousness by attacking references 
individually where the rejections are based on combinations of references. See In re Keller, 642 
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F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 
(Fed. Cir. 1986). Day-IBM discloses storing on an application server (e.g., col., 4, lines 42 - 55, 
figure 2) a multimedia file including a plurality groups of multimedia data (e.g., coL, 6, lines 45 - 
64); converting (e.g., col., 6, lines 21 - 25) at the streaming server (col., 3, lines 19-26, figures 
1 and 2), each of the media information received from the buffer (e.g., col., 4, lines 42 - 55, 
figures 1 and 2) and sending the multimedia data (e.g., coL, 5, lines 7 - 29), receiving of a client 
request (e.g., col., 5, lines 40-51) and converting of multimedia data (e.g., col., 6, lines 21 - 25) 
a format readable by the at least one client apparatus (e.g., col., 5, lines 36 - 48). Day-IBM also 
discloses usage of different servers including application server and a streaming server (e.g., col., 
4, lines 42 - 55, col., 3, lines 19 - 26, figures 1 and 2), and well-known concept of usage of the 
servers, i.e., combined or separated (e.g., col., 3, lines 21 -26). Saxena-IBM discloses the well- 
known concept of each group having a predetermined data size (e.g., col., 31, lines 1-41, 
figures 16-21), reading a client address corresponding to at least one client apparatus (e.g., col., 
22, lines 3 - 40, figures 7, 11), stripping consecutive groups (e.g., col., 31, lines 1-41, figures 
16-21) and buffering the consecutive groups in a staging buffer (e.g., col., 8, lines 44 - 56). 
Mattaway-NetSpeak discloses the well-known concept of determining in a request handler in the 
device a number of client requests from the at least one client apparatus for the information (e.g., 
col., 3, lines 4 - 38) and comparing the number of client requests for the information to a 
threshold number (e.g., col., 3, lines 4 - 38). With the combined teachings of Day- IBM, Saxena- 
IBM, Raz-AppStream and Mattaway-NetSpeak, the software would know how many client 
requests have occurred. The software would help perform action when the number of client 
requests is compared with the threshold number. Also, the specification, page 13, lines 16-19, 
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clearly states, "the scope of the present invention is not limited to data communication systems 
disclosed". Since, applicant's claims contain broadly claimed subject matter, it clearly reads 
upon the examiner*s interpretation of the claimed subject matter. Therefore, the rejection is 
maintained. 

Applicant argues (5), "the cited art Sabeti- Washington fails to teach or suggest claimed 

an application server and a streaming server and also fails to disclose anything regarding the 

transfer of a file between these two servers after a threshold number of requests are received. The 

examiner respectfully disagrees in response to applicant's arguments. The limitations of the 

claimed subject matter are rejected by combined teachings of Day- IBM, Saxena-IBM, Raz- 

AppStream, Mattaway-NetSpeak and Sabeti-Washington. In response to applicant's arguments 

against the references individually, one cannot show nonobviousness by attacking references 

individually where the rejections are based on combinations of references. See In re Keller, 642 

F.2d413,208 USPQ 871 (CCPA \9%\)\Inre MerckiScCo., 800 F.2d 1091,231 USPQ 375 

* 

(Fed. Cir. 1986). Day-IBM discloses storing on an application server (e.g., col., 4, lines 42 - 55, 
figure 2) a multimedia file including a plurality groups of multimedia data (e.g., col., 6, lines 45 - 
64); converting (e.g., col. ,,6, lines 21 - 25) at the streaming server (col., 3, lines 19-26, figures 
1 and 2), each of the media information received from the buffer (e.g., col., 4, lines 42 - 55, 
figures 1 and 2) and sending the multimedia data (e.g., col., 5, lines 7 - 29), receiving of a client 
request (e.g., col., 5, lines 40-51) and converting of multimedia data (e.g., col., 6, lines 21 - 25) 
a format readable by the at least one client apparatus (e.g., col., 5, lines 36 - 48). Day-IBM also 
discloses usage of different servers including application server and a streaming server (e.g., col., 
4, lines 42 - 55, col., 3, lines 19-26, figures 1 and 2), and well-knovra concept of usage of the 
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servers, i.e., combined or separated (e.g., col., 3, lines 21 -26). Saxena-IBM discloses the well- 
known concept of each group having a predetermined data size (e.g., col., 31, lines 1-41, 
figures 16-21), reading a client address corresponding to at least one client apparatus (e.g., col., 
22, lines 3 - 40, figures 7, 11), stripping consecutive groups (e.g., col., 31, lines 1-41, figures 
16-21) and buffering the consecutive groups in a staging buffer (e.g., col., 8, lines 44 - 56). 
Mattaway-NetSpeak discloses the well-known concept of determining in a request handler in the 
device a number of client requests from the at least one client apparatus for the information (e.g., 
col., 3, lines 4 - 38) and comparing the number of client requests for the information to a 
threshold number (e.g., col., 3, lines 4 - 38). Sabeti-Washington teaches the well-known concept 
of transferring the entire information from the first device to the second device when the number 
of client requests is greater than the threshold number (e.g., col., 2, lines 5 - 25). With the 
combined teachings of Day-IBM, Saxena-IBM, Raz-AppStream, Mattaway-NetSpeak, and 
Sabeti-Washington the software would help support the number of client requests. Having the 
entire information transferred would help the software to access the entire information in order to 
support the requests. The entire information would help the software to support the client 
requests based on the information requested in each of the requests. Also, the specification, page 
13, lines 16-19, clearly states, "the scope of the present invention is not limited to data 
communication systems disclosed". Since, applicant's claims contain broadly claimed subject 
matter, it clearly reads upon the examiner's interpretation of the claimed subject matter. 
Therefore, the rejection is maintained. 

Applicant argues (6), "the cited art Brodersen et al,, Siebel Systems, 6,732,1 1 1 
(Hereinafter Brodersen-Siebel) fails to teach or suggest claimed the determination of a rate of 
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sending multimedia from a streaming server to a client, the comparison of this rate to a threshold, 
and the purging of the multimedia file when the rate is less than the threshold". The examiner 
respectfully disagrees in response to applicant's arguments. The limitations of the claimed 
subject matter are rejected by combined teachings of Day-IBM, Saxena-IBM, Raz-AppStream, 
Mattaway-NetSpeak, Sabeti- Washington and Brodersen-Siebel. In response to applicant's 
arguments against the references individually, one cannot show nonobviousness by attacking 
references individually where the rejections are based on combinations of references. See In re 
Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 
USPQ 375 (Fed. Cir. 1986). Day-IBM discloses storing on an application server (e.g., col., 4, 
lines 42-55, figure 2) a multimedia file including a plurality groups of multimedia data (e.g., 
col., 6, lines 45 - 64); converting (e.g., col., 6, lines 21-25) at the streaming server (col., 3, lines 
19-26, figures 1 and 2), each of the media information received from the buffer (e.g., col., 4, 
lines 42 - 55, figures 1 and 2) and sending the multimedia data (e.g., col., 5, lines 7 - 29), 
receiving of a client request (e.g., col., 5, lines 40-51) and converting of multimedia data (e.g., 
col., 6, lines 21 - 25) a format readable by the at least one client apparatus (e.g., col., 5, lines 36 - 
48). Day-IBM also discloses usage of different servers including application server and a 
streaming server (e.g., col., 4, lines 42 - 55, col., 3, lines 19-26, figures 1 and 2), and well- 
known concept of usage of the servers, i.e., combined or separated (e.g., col., 3, lines 21 -26). 
Saxena-IBM discloses the well-known concept of each group having a predetermined data size 
(e.g., col., 31, lines 1-41, figures 16-21), reading a client address corresponding to at least one 
client apparatus (e.g., col., 22, lines 3 - 40, figures 7, 11), stripping consecutive groups (e.g., 
col., 3 1, lines 1-41, figures 16-21) and buffering the consecutive groups in a staging buffer 
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(e.g., col., 8, lines 44 - 56). Mattaway-NetSpeak discloses the well-known concept of 
determining in a request handler in the device a number of client requests from the at least one 
client apparatus for the information (e.g., col., 3, lines 4 - 38) and comparing the number of 
client requests for the information to a threshold number (e.g., col., 3, lines 4 - 38). Sabeti- 
Washington teaches the well-known concept of transferring the entire information from the first 
device to the second device when the number of client requests is greater than the threshold 
number (e.g., col., 2, lines 5 - 25). Brodersen-Siebel discloses the well-known concept of a rate 
of sending of the file from the device to the client apparatus (e.g., col., 2, line 4 - col., 3, line 14), 
comparing the rate of sending to a threshold number (e.g., coL, 2, line 4 - col., 3, line 14), 
purging the file from the device when the rate of sending is less than the threshold number (e.g., 
col., 3, line 9 - col., 4, line 24). With the combined teachings of Day-IBM, Saxena-IBM, Raz- . 
AppStream, Mattaway-NetSpeak, Sabeti-Washington and Brodersen-Siebel the threshold 
number would help the software know when to purge the information including the file. The 
comparison of the rate of sending the file with the threshold number would help the software to 
handle the information of the device. The predetermined time period would help the software 
decide when to purge the information from the device. Also, the specification, page 13, lines 16- 
19, clearly states, "the scope of the present invention is not limited to data communication 
systems disclosed". Since, applicant's claims contain broadly claimed subject matter, it clearly 
reads upon the examiner's interpretation of the claimed subject matter. Therefore, the rejection 
is maintained. 

Applicant argues (7), that limitation "converting after comparing and waiting a 
predetermined time", is not well known in the art. The examiner respectfiiUy disagrees in 
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response to applicant's arguments. For example, Bommaiah et al., 6,708,213, discloses these 
limitations, e.g., col., 4, lines 53 - 63, col., 14, lines 31-50; Cousins, 6,618,385, discloses these 
limitations, e.g., col., 3, lines 42 - 58, col., 6, lines 27 - 60; Downing et al., 6,373,855, discloses 
these limitations, e.g., col., 2, lines 62 - col., 3, line 15, col., 4, lines 39 - 59; Vaid et al., 
6,078,953, discloses these limitations, e.g., col., 18, lines 2 - 24; Bowman, IV et al., US 
2003/0050535, Mar 13, 2003, paragraphs 148, 157; Young et al., 5,838,950, e.g., col., 69, line 47 

- col., 70, line 25; Bloomfield et al., US 2001/0036322, Nov 1, 2001, paragraphs 97, 106; Yavits 
et al., US 2004/0136459, discloses these limitations, e.g., paragraphs 133, 134, col., 12, lines 25 

- 54; Campbell et al., US 2003/0140159, Jul 24, 2003, paragraphs 147, 159; Yik et al., US 
2002/0093964, Jul 18, 2002, paragraphs 6, 18; Gerhart et al., US 2003/0023790, Jan 30, 2003, 
paragraphs 20, 21, 26; Suvanen et al., 6,320,880, discloses these limitations, e.g., col., 4, lines 
16-48, col., 10, lines 8-15, Enari, 6,747,998, discloses these limitations, e.g., col., 4, line 49 - 
col., 5, line 18; Hart, 6,408,310, discloses these limitations, e.g., col., 4, lines 31 - 67. The claim 
is open-ended (comprising), also, the specification, page 13, lines 16-19, clearly states, "the 
scope of the present invention is not limited to data communication systems disclosed". Since, 
applicant's claims contain broadly claimed subject matter, it clearly reads upon the examiner's 
interpretation of the claimed subject matter. Therefore, the rejection is maintained. 

Claim Rejections - 35 USC § 103 

3. ' The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 

obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
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having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made, 

4. Claims 1, 4, 5, are rejected under 35 U.S.C. 103(a) as being unpatentable over Day et al., 
IBM, 5,996,015 (Hereinafter Day-IBM) in view of Saxena et al., 5,805,821, IBM (Hereinafter 
Saxena-IBM) and Raz et al., U.S. Publication 2002/0138640, AppStream (Hereinafter Raz- 
AppStream). 

5. As per claim 1 , Day-IBM clearly teaches a method for transferring multimedia data (e.g., 
col., 5, lines 35 - 53, col., 6, lines 26 - 60, figure 2) using a data communication system (e.g., 
figure 1) comprising the steps of: 

storing on an application server (e.g., col., 4, lines 42 - 55, figure 2) a multimedia file 
including a plurality groups of multimedia data (e.g., col., 6, lines 45 - 64); 

receiving a client request at the application server (e.g., col., 5, lines 40 - 51); 

transferring (e.g., col., 3, lines 12 - 51) to a streaming server (e.g., col., 3, lines 12 - 38, 
figures 1 and 2) information fi'om the buffer (e.g., col., 4, lines 42 - 55, figures 1 and 2), 

converting (e.g., col., 6, lines 21 - 25) at the streaming server (col., 3, lines 19-26, 
figures 1 and 2), each of the media information received from the buffer (e.g., col., 4, lines 42 - 
55, figures 1 and 2) into a format readable by the at least one client apparatus (e.g., col., 5, lines 
36 - 48), and 

sending each of the consecutive groups to the at least one client apparatus (e.g., col., 5, 
lines 7 - 29). 

However, Day-IBM does not specifically mention about each group having a 
predetermined data size, reading a client address corresponding to at least one client apparatus, 
stripping consecutive groups and buffering the consecutive groups in a staging buffer. 
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Saxena-IBM discloses the well-known concept of each group having a predetermined 
data size (e.g., col., 31, lines 1-41, figures 16-21), reading a client address corresponding to at 
least one client apparatus (e.g., col., 22, lines 3 - 40, figures 7, 1 1), stripping consecutive groups 
(e.g., col., 31, lines 1-41, figures 16 - 21) and buffering the consecutive groups in a staging 
buffer (e.g., col, 8, lines 44 - 56). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Day- IBM with the teachings of Saxena-IBM in order to 
facilitate each group having a predetermined data size, reading a client address corresponding to 
at least one client apparatus, stripping consecutive groups and buffering the consecutive groups 
in a staging buffer because the stripping of the consecutive groups would help select necessary 
data. The consecutive data would help the software to process the information to support the 
client. The staging buffer would help store stripped information in a consecutive manner. Group 
having a predetermined data size would help the software to process data for the client. The 
client address would help the device to support transfer of data to the client. 

However, Day-IBM and Saxena-IBM do not specifically mention about selectively 
storing on at least one of the servers based on a number of client requests received. 

Raz-AppStream discloses the well-known concept of selectively storing on at least one of 
the servers (e.g., at least one of the intermediate servers 190 or 200, figure 3-5, paragraph 39, 
col., 4, also usage of one of the node based on shortest path, paragraph 64, col., 7, paragraphs 15, 
17 and 19, col., 2) based on a number of client requests received (e.g., number of clients utilizing 
streaming information, paragraph 54, historical count of the number of times a client made 
request, paragraph 69, col., 8). 
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It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Day-IBM and Saxena-IBM with the teachings of Raz- 
AppStream in order to facilitate selectively storing on at least one of the servers based on a 
number of cHent requests received because the concept of utilizing number of client requests 
received would let the system know which information is most frequently used by the client. The 
system would store and provide the information in one of the servers, which would enhance 
improving the delivery time to the client(s). 

6. As per claim 4, Day-IBM, Saxena-IBM and Raz-AppStream disclose the claimed 
limitations as rejected above. Day-IBM also teaches the at least one cHent apparatus is selected 
from a group consisting of: a personal computer, a fax machine, a hard drive, a telephone 
interface, a wireless telephone, a radio receiver, and a personal digital assistant (e.g., figures 1 
and 2). 

7. As per claim 5, Day-IBM, Saxena-IBM and Raz-AppStream disclose the claimed 
limitations as rejected above. Day-IBM also teaches the multimedia file is selected from a group 
consisting of: video files, music files, computer generated graphics files, still image files, and 
sound files (e.g., col., 6, lines 15 - 30, col., 3, lines 18 - 24). 

8. Claims 2, 3 are rejected under 35 U.S.C. 103(a) as being unpatentable over Day-IBM, 
Saxena-IBM and Raz-AppStream in view of Akeley, Silicon Graphics, 5,933,155 (Hereinafter 
Akeley-Silicon-Graphics). 
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9. As per claims 2 and 3, Day-IBM, Saxena-IBM and Raz-AppStream disclose the claimed 
limitations as rejected above. Day-IBM also teaches the multimedia file is a video file / MPEG 
format (e.g., col., 3, lines 18 - 24). However, Day-IBM, Saxena-IBM and Raz-AppStream do 
not specifically mention about multimedia data comprises a video frame, each frame corresponds 
to a frame display duration, and the rate at which consecutive frames are transferred to a device 
from the buffer corresponds to intervals of each display duration. 

Akeley-Silicon-Graphics discloses the well-knovm concept of multimedia data comprises 
a video frame (e.g., figures 1-3, col., 3, line 26 - col., 4, line 64), each frame corresponds to a 
frame display duration (e.g., figures 1-3, col., 3, line 26 - col., 4, line 64), and the rate at which 
consecutive frames are transferred to a device from the buffer corresponds to intervals of each 
display duration (e.g., figures 1-3, col., 3, line 26 - col., 4, line 64). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Day-IBM, Saxena-IBM and Raz-AppStream with the 
teachings of Akeley-Silicon-Graphics in order to facilitate a multimedia data comprises a video 
frame corresponding to a frame display duration and the rate at which consecutive frames are 
transferred to a device from the buffer correspond to intervals of each display duration because 
the video frame display duration information would help software to handle the video frame for 
the client. The rate at which the consecutive frames are transferred would help software for 
adjusting the video information provided to the client. 

10. Claim 6 is rejected under 35 U.S.C. 103(a) as being unpatentable over Day-IBM, Saxena- 
IBM and Raz-AppStream in view of Kessler et al.. Sun Microsystems, 6,681,306 (Hereinafter 
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Kessler-Sun), Eylon et al., AppStream, U.S. Publication 2001/0034736 (Hereinafter Eylon- 
AppStream) and Srikantan et al., Sun Microsystems, 6,857,130 (Hereinafter Srikantan-Sun). 
11. As per claim 6, Day-IBM, Saxena-IBM and Raz- AppStream teach the claimed 
limitations as rejected above. However, Day-IBM, Saxena-IBM and Raz-AppStream do not 
specifically mention about determining, in the device according to a garbage-collection 
algorithm and whether there is sufficient space in the device to hold the information from the 
memory before the device transfers the information from the memory to the device. 

Kessler-Sun discloses the well-known concept of determining in the device according to 
a garbage-collection algorithm (e.g., col., 3, lines 14 - 38) and whether there is sufficient space 
in the device to hold the information from the memory before the device transfers the 
information from the memory to the device (e.g., col., 3, lines 14 - 38). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Day-IBM, Saxena-IBM and Raz- AppStream with the 
teachings of Kessler-Sun in order to facilitate usage of a garbage-collection algorithm and to 
check whether there is sufficient space in the device to hold the information from the memory 
before the device transfers the information from the memory to the device because the garbage 
collection would help remove unnecessary data from the memory. By checking whether 
sufficient memory space exist, the software would help handle the information for processing. 

Day-IBM, Saxena-IBM, Raz-AppStream and Kessler-Sun do not specifically mention 
about purging information from the device when it is determined that there is not sufficient space 
in the streaming server to hold the information from the buffer. 
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Eylon-AppStream discloses the well-known concept of purging information from the 
device when it is determined that there is not sufficient space in the streaming server to hold the 
information from the buffer (e.g., col., 4, lines 5 - 42). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Day-IBM, Saxena-IBM, Raz-AppStream and Kessler-Sun 
with the teachings of Eylon-AppStream in order to facilitate purging information from the device 
when it is determined that there is not sufficient space in the streaming server to hold the 
information from the buffer because the purging would help regain memory space. The regained 
memory space would help provide storage space to the software for the information that needs to 
be stored. 

Day-IBM, Saxena-IBM, Raz-AppStream, Kessler-Sun and Eylon-AppStream do not 
specifically mention about sending notice of a new client to the streaming server. 

Srikantan-Sun discloses the well-knovm concept of sending notice of a new client to the 
device (e.g., figure 1, col., 3, lines 39 - 59). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Day-IBM, Saxena-IBM, Raz-AppStream, Kessler-Sun 
and Eylon-AppStream with the teachings of Srikantan-Sun in order to facilitate sending notice of 
a new client to the device because the notice would help inform the software. The software 
would help support the new client. 
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12. Claims 7 and 8 are rejected under 35 U.S.C. 103(a) as being unpatentable over Day-IBM, 
Saxena-IBM and Raz-AppStream, in view of Lin et al., Lucent Technologies, 6,405,256 
(Hereinafter Lin-Lucent) and "Official Notice". 

13. As per claims 7 and 8, Day-IBM, Saxena-IBM and Raz-AppStream teach the claimed 
limitations as rejected above. However, Day-IBM, Saxena-IBM and Raz-AppStream do not 
specifically mention about determining at the first device, a transfer rate from the second device 
to the first device and a sending rate from the first device to the at least one client apparatus; and 
comparing the transfer rate to the sending rate. 

Lin-Lucent discloses the well-known concept of determining at the first device, a transfer 
rate fi*om the second device to the first device and a sending rate from the first device to the at 
least one client apparatus (e.g., col., 4, lines 8 - 43), comparing the transfer rate to the sending 
rate and performing the action when the sending rate is greater than the transfer rate (e.g., col., 4, 
lines 8 -43). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Day-IBM, Saxena-IBM and Raz-AppStream with the 
teachings of Lin-Lucent in order to facilitate determining at the first device, a transfer rate fi-om 
the second device to the first device and a sending rate from the first device to the at least one 
client apparatus and comparing the transfer rate to the sending rate and performing the action 
when the sending rate is greater than the transfer rate because the comparison between the two 
rates would help the software to handle the information based on the transfer rate and the sending 
rate. Performing the action would help the software to not lose the information for the client. 
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Day-IBM, Saxena-IBM, Raz-AppStream and Lin-Lucent do not specifically mention 
about perforaiing the comparing step and waiting a predetermined time period before the device 
performs the converting step. 

"Official Notice" is taken that both the concept and advantages of the converting after 
comparing and waiting a predetermined time period is well known and expected in the art. 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to include performing the converting after comparing and waiting a predetermined 
time period with the teachings of Day-IBM, Saxena-IBM, Raz- AppStream and Lin-Lucent in 
order to facilitate conversion of information done after the comparison of transfer rates because 
the comparison would help gather all the information before the information is converted. 
Waiting a predetermined time period before the device performs the converting would help the 
information to be collected in order to support the converting. 

14. Claims 9 and 10 are rejected under 35 U.S.C. 103(a) as being unpatentable over Day- 
IBM, Saxena-IBM and Raz- AppStream in view of Mattaway et al, NetSpeak Corporation, 
6,185,184 (Hereinafter Mattaway-NetSpeak) and Sabeti, Washington, U.S. 2002/0023127 
(Hereinafter Sabeti- Washington). 

15. As per claims 9 and 10, Day-IBM, Saxena-IBM and Raz- AppStream teach the claimed 
limitations as rejected above. However, Day-IBM, Saxena-IBM and Raz-AppStream do not 
specifically mention about determining in a request handler in the device a number of client 
requests fi*om the at least one client apparatus for the information and comparing the number of 
client requests for the information to a threshold number. 
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Mattaway-NetSpeak discloses the well-known concept of determining in a request 
handler in the device a number of client requests from the at least one client apparatus for the 
information (e.g., col., 3, lines 4 - 38) and comparing the number of client requests for the 
information to a threshold number (e.g., col., 3, lines 4 - 38). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Day-IBM, Saxena-IBM and Raz-AppStream with the 
teachings of Mattaway-NetSpeak in order to facilitate determining number of client requests 
from the at least one client apparatus for the information and comparing the number of client 
requests for the information to a threshold number because the software would know how many 
client requests have occurred. The software would help perform action when the number of 
client requests is compared with the threshold number. 

Day-IBM, Saxena-IBM, Raz-AppStream and Mattaway-NetSpeak do not specifically 
mention about transfering the entire information from the first device to the second device when 
the number of client requests is greater than the threshold number. 

Sabeti-Washington teaches the well-known concept of transferring the entire information 
from the first device to the second device when the number of client requests is greater than the 
threshold number (e.g., col., 2, lines 5 - 25). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Day-IBM, Saxena-IBM, Raz-AppStream and Mattaway- 
NetSpeak with the teachings of Sabeti-Washington in order to facilitate transferring the entire 
information from the first device to the second device when the number of client requests is 
greater than the threshold number because the software would help support the number of client 



Application/Control Number: 09/736,258 Page 20 

Art Unit: 2154 

requests. Having the entire information transferred would help the software to access the entire 
information in order to support the requests. The entire information would help the software to 
support the client requests based on the information requested in each of the requests. 

16. Claims 1 1 and 12 are rejected under 35 U.S.C. 103(a) as being unpatentable over Day- 
IBM, Saxena-IBM and Raz-AppStream in view of Kessler-Sun and Brodersen et al., Siebel 
Systems, 6,732,1 1 1 (Hereinafter Brodersen-Siebel). 

17. As per claims 1 1 and 12, Day-IBM, Saxena-IBM and Raz-AppStream teach the claimed 
limitations rejected under claim 1. However, Day-IBM, Saxena-IBM and Raz-AppStream do not 
specifically mention about determining, in the device according to a garbage-collection 
algorithm. 

Kessler-Sun discloses the well-known concept of determining in the device according to 
a garbage-collection algorithm (e.g., col., 3, lines 14 - 38). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Day-IBM, Saxena-IBM and Raz-AppStream with the 
teachings of Kessler-Sun in order to facilitate usage of a garbage-collection because the garbage 
collection would help remove urmecessary data from the memory. 

Day-IBM, Saxena-IBM, Raz-AppStream and Kessler-Sun do not specifically mention 
about a rate of sending of the file from the device to the client apparatus, comparing the rate of 
sending to a threshold number, purging the file from the device when the rate of sending is less 
than the threshold number, wherein the rate of sending is a number of times the file has been sent 
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over a predetermined time period, and the predetermined time period is selected from a group 
consisting of one minute, one hour, one day, one week, one month, and one year. 

Brodersen-Siebel discloses the well-known concept of a rate of sending of the file from 
the device to the client apparatus (e.g., col., 2, line 4 - col., 3, line 14), comparing the rate of 
sending to a threshold number (e.g., col., 2, line 4 - col., 3, line 14), purging the file from the 
device when the rate of sending is less than the threshold number (e.g., col., 3, line 9 - col., 4, 
line 24), wherein the rate of sending is a number of times the file has been sent over a 
predetermined time period (e.g., col., 3, line 9 - col., 4, line 24), and the predetermined time 
period is selected from a group consisting of one minute, one hour, one day, one week, one 
month, and one year (e.g., col., 3, line 9 - col., 4, line 24). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Day-IBM, Saxena-IBM, Raz-AppStream and Kessler-Sun 
with the teachings of Brodersen-Siebel in order to facilitate comparing a rate of sending of the 
file from the device to a threshold number for purging when the rate of sending is less than the 
threshold number because the threshold number would help the software know when to purge the 
information including the file. The comparison of the rate of sending the file with the threshold 
number would help the software to handle the information of the device. The predetermined 
time period would help the software decide when to purge the information from the device. 

18. Claims 13 and 14 are rejected under 35 U.S.C. 103(a) as being unpatentable over Day- 
IBM, Saxena-IBM and Raz-AppStream in view of Kessler-Sun, Brodersen-Siebel and Gustman, 
Survivors Foundafion, 5,832,499 (Hereinafter Gustman-Survivors). 
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19. As per claims 13 and 14, Day-IBM, Saxena-IBM and Raz-AppStream teach the claimed 
limitations as rejected aboce. However, Day-IBM, Saxena-IBM and Raz-AppStream do not 
specifically mention about determining, in the device according to a garbage-collection 
algorithm. 

Kessler-Sun discloses the well-known concept of determining in the device according to 
a garbage-collection algorithm (e.g., col., 3, lines 14 - 38). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Day-IBM, Saxena-IBM and Raz-AppStream with the 
teachings of Kessler-Sun in order to facilitate usage of a garbage-collection because the garbage 
collection would help remove unnecessary data from the memory. 

Day-IBM, Saxena-IBM, Raz-AppStream and Kessler-Sun do not specifically mention 
about a rate of sending of the file from the device to the client apparatus, comparing the rate of 
sending to a threshold number, wherein the rate of sending is a number of times the file has been 
sent over a predetermined time period, and the predetermined time period is selected from a 
group consisting of one minute, one hour, one day, one week, one month, and one year. 

Brodersen-Siebel discloses the well-known concept of a rate of sending of the file from 
the device to the client apparatus (e.g., col., 2, line 4 - col., 3, line 14), comparing the rate of 
sending to a threshold number (e.g., col., 2, line 4 - col., 3, line 14), wherein the rate of sending 
is a number of times the file has been sent over a predetermined time period (e.g., col., 3, line 9 - 
col., 4, line 24), and the predetermined time period is selected from a group consisting of one 
minute, one hour, one day, one week, one month, and one year (e.g., col., 3, line 9 - col., 4, line 
24). 
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It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Day-IBM, Saxena-IBM, Raz-AppStream and Kessler-Sun 
with the teachings of Brodersen-Siebel in order to facilitate comparing a rate of sending of the 
file from the device to a threshold number for purging when the rate of sending is less than the 
threshold number because the threshold number would help the software to decide on when to 
purge the information including the file. The comparison of the rate of sending the file with the 
threshold number would help the software to handle the information of the device. The 
predetermined time period would help the software decide on purging the information fi"om the 
device. 

Day-IBM, Saxena-IBM, Raz-AppStream, Kessler-Sun and Brodersen-Siebel do not 
specifically mention about keeping the file stored on the device when the rate of sending is 
greater than the threshold number. 

Gustman-Survivors discloses the well-known concept of keeping the file stored on the 
device when the rate of sending is greater than the threshold number (e.g., col., 2, lines 3 - 58). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Day-IBM, Saxena-IBM, Raz-AppStream, Kessler-Sun 
and Brodersen-Siebel with the teachings of Gustman-Survivors in order to facilitate keeping the 
file stored on the device when the rate of sending is greater than the threshold number because 
the threshold number would help the software to decide on when to not purge the information 
including the file. The threshold number would help the software decide to not purging the 
information from the device. 
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20. Claim 15 is rejected under 35 U.S.C. 103(a) as being unpatentable over Day-IBM, 
Saxena-IBM and Raz-AppStream in view of Thro et al., Motorola, 6,037,991 (Hereinafter Thro- 
Motorola). 

21 . As per claim 1 5, Day-IBM, Saxena-IBM and Raz-AppStream teach the claimed 
limitations as rejected above. However, Day-IBM, Saxena-IBM and Raz-AppStream do not 
specifically mention about determining in a time-division multiplexer program in the device a 
priority order for sending the information when there are plurality of client apparatus. 

Thro-Motorola discloses the well-known concept of determining in a time-division 
multiplexer program in the device a priority order for sending the information when there are 
plurality of client apparatus (e.g., col., 4, lines 8 - 42, figure 1). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Day-IBM, Saxena-IBM and Raz-AppStream with the 
teachings of Thro-Motorola in order to facilitate usage of a time-division multiplexer program 
and a priority order for sending the information because the time-division multiplexing would 
help handle a plurality of clients. The priority order would help software to provide information 
to the plurality of clients. 

Conclusion 

22. The prior art made of record (forms PTO-892 and applicant provided IDS cited arts) and 
not relied upon is considered pertinent to applicant's disclosure. 

THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 
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A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 

Examiner has cited particular columns and line numbers and/or paragraphs and/or 
sections and/or page numbers in the reference(s) as applied to the claims above for the 
convenience of the applicant. Although the specified citations are representative of the teachings 
of the art and are applied to the specific limitations within the individual claim, other passages 
and figures may apply as well. It is respectfully requested from the applicant in preparing 
responses, to fully consider the references in entirety, as potentially teaching, all or part of the 
claimed invention, as well as the context of the passage, as taught by the prior art or disclosed by 
the Examiner. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Haresh Patel whose telephone number is (571) 272-3973. The 
examiner can normally be reached on Monday, Tuesday, Thursday and Friday from 10:00 am to 
8:00 pm. 
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If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, John Follansbee can be reached on (571) 272-3964. The fax phone number for the 
organization where this application or proceeding is assigned is (571) 273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 

Haresh Patel 



October 11,2005 




